Hi @bagnaram. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: bagnaram
To complete the pull request process, please assign justinsb
You can assign the PR to them by writing /assign @justinsb in a comment when ready.

The full list of commands accepted by this bot can be found here.

This is preliminary support for etcd on additional EBS volumes. Currently, this PR requires manual modification of the KubeadmControlPlane resource to mitigate a kubeadm bug kubernetes/kubeadm#2127

apiVersion: controlplane.cluster.x-k8s.io/v1alpha3
kind: KubeadmControlPlane
spec:
  kubeadmConfigSpec:
    preKubeadmCommands:
    - if [ -d "/var/lib/etcd/lost+found" ]; then rm -Rf /var/lib/etcd/lost+found; fi

Also it is worth noting that the way of programmatically creating the EBS volume and attaching is a bit brittle, as it relies on hijacking the UserData creation by the AWSMachineController

@bagnaram There is a proposal that would allow cloud-init to get disks setup kubernetes-sigs/cluster-api#2994

I am re-working the PR to include the changes made in kubernetes-sigs/cluster-api@master...CecileRobertMichon:etcd-mount to include an updated cloudinit with file-system params

Now requires kubernetes-sigs/cluster-api@master...CecileRobertMichon:etcd-mount

The UserData is provided by the bootstrap controller, therefore it is necessary to identify the device type that is being attached via EBS. This is hardcoded in the KubeadmConfigTemplate and the KubeadmControlPlane manifest. The UX needs to be determined for automating this process between the bootstrap provider and the infrastructure because currently there isn't a way to pass this type of information. Possible options include nvme-tools to detect inside the instance.

opened kubernetes-sigs/cluster-api#3066

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@bagnaram: PR needs rebase.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

@fejta-bot: Closed this PR.